Method for distributing promotional offers using an electronic game application

ABSTRACT

Methods are provided that allow promotional offers to be distributed through the play of an electronic game application. The method may include use of a handheld device, location-based targeting of offers such as deals, advertisements, and coupons, and offer prioritization based on user playing history. The method may involve a server through which offers are distributed. The method may include receiving requests from sponsors to create promotional offers. In some embodiments, the use of rank in a high score database may help determine which players receive a prize.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to computer systems. Inparticular, the present invention relates to a method for distributingpromotional offers using an electronic game application.

2. Description of the Related Art

On handheld computing devices, the play of short, simple games and theuse of targeted location-based advertising have become widespread. Manymobile game applications and online browser-based games have alocation-based advertising and sponsorship feature. These games allowthe user to play, and in between rounds of the game, play is interruptedto display an advertisement.

SUMMARY OF THE INVENTION

A method for distributing promotional offers using an electronic gameapplication is disclosed.

According to one embodiment, a user opens an application or web browseron a user device, preferably a mobile phone. The user device sends arequest to a server for currently available potential offers. The serversearches its database of potential offers from vendors based on locationdata for the user's account or device, where at least one of thepotential offers from at least one of the vendors has a game associatedwith it, the play of which allows for a score to be determined thataffects the offer to be made, and returns the search results as a listto the user device. Preferably, several of the potential offers havesuch games associated with them. A game is presented to the user throughthe user device, and a score is calculated at some point after play ascommenced, typically at the conclusion of the game. Preferably, thescore is stored in a high-score database, and an activated offer ispresented to the user. The activated offer may depend on the user's rankin the high-score database. The activated offer may be presented at theconclusion of play or at a later time such as the end of a tournament,or upon the reach of a suitable score or rank, depending on how the gameand potential offer are configured. Activated offers may be redeemed,for example, by way of a numeric code or barcode provided to the user,or by way of a near-field communications link from the merchant'spoint-of-sale terminal to the user's mobile phone.

According to another embodiment, a first activated offer is presented toplayers who do not meet a performance bar or rank, and a secondactivated offer is presented only to players who meet the performancebar or rank. The decision to award the second activated offer could bemade during play, immediately after play, or at a later time such as theconclusion of a tournament, competition, or offer period.

Preferably, the server exposes a management interface to sponsors toreceive requests to create, read, update, or delete potential offers, orto process redemptions of activated offers, or to view statistics aboutusers who have attempted to receive potential offers, or to viewstatistics about activated offers, or to view billing information.

Preferably, the server also receives requests made over a telephone bysponsors to process redemptions.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a preferred embodiment of a system fordistributing promotional offers using an electronic game applicationincorporating applicant's invention.

FIG. 2 is a connection flow diagram suitable for use in the inventionshown in FIG. 1.

FIGS. 3-7 are screen shots of five displays on user terminal 105 of FIG.1.

FIG. 8 is a connection flow diagram suitable for use in the inventionshown in FIG. 1.

DETAILED DESCRIPTION

In the present invention, “potential offer” indicates an offer that isavailable for one or more users to receive through play of a game.Offers may include, but are not limited to, deals, advertisements, andcoupons.

In the present invention, “activated offer” indicates an offer which hasbeen provided to a user through play of a game. “Activated offer” couldalso reasonably be referred to as a coupon or reward.

In the present invention, “offer code” indicates an identifiercorresponding to an activated offer which a user may use to redeem anactivated offer.

In the following descriptions, exemplary embodiments of the inventionare shown. Reference numerals correspond to numerals from the drawings.

FIG. 1 is an overview illustrating an offer distribution systemaccording to an exemplary embodiment of the invention.

The user terminal 105 corresponds to an Internet-connected computer orinteractive device such as a mobile phone, tablet, laptop PC, desktopPC, television, or other electronic device with a web browser or anapplication for offer distribution. In a preferred embodiment, userterminal 105 is a smartphone. In certain embodiments multiple userterminals will be connected to the network simultaneously.

The user terminal 105 is connected to a network, preferably theInternet, through link 110. This link may be a cellular data link suchas GSM (Global System for Mobile communication), GPRS (General PacketRadio Service), 1xEV-DO, UMTS (Universal Mobile TelecommunicationsSystem), LTE (Long Term Evolution), or other cellular data systems aswill be apparent to one having skill in the art. The link 110 may alsobe a wired or fiber-optic connection, or it may use a medium-rangewireless communication standard such as Wi-Fi™. The link 110 may alsouse a short-range standard such as Bluetooth® to relay packets throughanother device using any of the standard connection technologiesmentioned above.

The purpose of user terminal 105 is to present potential offers, games,and activated offers to the user, and to allow users to play games tocompete for offers. User terminal 105 communicates with server 120 toprovide information such as authentication, gameplay, and locationinformation; and to receive information such as lists of potentialoffers.

Network 115 is a network such as the Internet. In alternativeembodiments multiple disparate networks may be used to connect differentelements of the system. For example, in certain embodiments vendorterminal 140 is connected to server 120 via a connection involving thePSTN (public switched telephone network), but user terminal 105 is stillconnected to server 120 via the public Internet.

Server 120 processes offer and user information. In a preferredembodiment it receives and responds to requests for offer and userinformation and processing from users, sponsors, and vendors. In certainembodiments server 120 may be a cluster of servers, preferably managedby way of a load balancer, or a virtual machine to be run on a grid ofservers in a cloud computing-style system. The functionality of server120 may also be divided into multiple logical units, potentially run byindependent systems. For example, social networking services may providesingle sign-on functionality on an independent server; captcha servicesmay provide captcha functionality on an independent server; user-,vendor-, and sponsor-facing components may be hosted on differentservers or on mirrored servers or on a content distribution network. Ina preferred embodiment, server 120 is a Windows™ or Linux™ systemrunning a Java™ virtual machine, Tomcat™ application server to host webservices to respond to REST requests using XML messages, and Apache™ webserver.

Database 125 represents backend storage for the functionality of server120. Data stored by database 125 for each user includes name, password,email, phone number, demographics including age, gender, location,sexual orientation, social network affiliation, and type of device used.Database 125 also stores potential offer information, valid locationsfor potential offers, targeted demographics for a potential offer, oneor more games corresponding to a potential offer. For activated offers,database 125 stores information such as redemption codes, flags toindicate viewing, printing, and redemption of potential offers, creationand expiration dates, creator, and last modifier. Database 125 stores atable of high scores for a particular game, tournament, or potentialoffer. For potential offers, database 125 stores an identifier, sponsorID, caption, expiration date, game type, category, description, startdate, creation date, modified date, winner identification, an image,creator information, modifier information, and a flag to indicatewhether the offer is active, pending, or has been won. Database 125 alsostores UUIDs (serial numbers) for user devices. Database 125 also storesa table of active user sessions. Database 125 also stores a table of thetypes of games available. Database 125 also stores sponsor logins andpasswords, vendor logins and passwords, and analytics information.Database 125 is preferably a standard relational database, but may alsobe a flat file or a distributed storage service such as Amazon 53″(Simple Storage Service) or Amazon SimpleDB™, or another type ofdatabase. Database 125 may be divided into multiple locations orfunctionalities.

Social networking server 135 is preferably a server providing aninterface such as the Facebook Connect™ platform. Social networkingserver 135 may act as an authentication server. Server 120 may sendsocial networking server 135 requests for authentication for users,sponsors, or vendors, and social networking server 135 may send server120 authentication token replies. Server 120 may also send socialnetworking server 135 requests for posting to a wall or news feed whenthe user requests that a potential offer, a game, or a user'sperformance in a game be shared.

Sponsor terminal 130 can be any Internet-connected computer orinteractive device, such as a mobile phone, tablet, laptop PC, desktopPC, television, or other electronic device with a web browser or anapplication. The sponsor uses sponsor terminal 130 to communicate withserver 120 using an application or web application. The application orweb application allows the sponsor to create, read, update, or deleteoffers, tournaments, and offer metadata such as demographic and locationtargeting. The application or web application also provides updatedbilling data and analytics data to the sponsor.

The vendor and the sponsor are expected to be the same entity in mostcases. Sponsor terminal 130 may be used by the sponsor's marketing staffwhile vendor terminal 140 may be used by the sponsor's retail locations.Vendor terminal 140 is preferably an Internet connected point-of-saleterminal but could also be a PC, a mobile phone, or other device usablefor computerized retail sales. Vendor terminal 140 could also be thebackend of an e-commerce server. The vendor terminal 140 receives anoffer code and sends the offer code to the server 120 for verificationand/or redemption, preferably through a web application or XML webservices API. Upon verification of the offer code by server 120, server120 notifies vendor terminal 140, and vendor terminal 140 indicates tothe vendor that the offer code is valid. Upon redemption of the offercode by server 120, server 120 notifies vendor terminal 140, and vendorterminal 140 indicates to the vendor that redemption is complete.Redemption of the activated offer using the offer code causes at leastpart of the value of the activated offer to no longer be usable, andinformation to this effect is recorded by server 120 in database 125.

Vendor terminal 140 could be replaced in some embodiments by a telephoneor text message based redemption system, whereby an activated offer codeis sent by the vendor in a phone call, e-mail, or text message toprocess the verification and/or redemption, and confirmation of theverification and/or redemption is sent back to the vendor over phone,e-mail, or text message. Alternatively, a video call could be used: insuch an embodiment, scanner 145 would be a camera, and the barcode readby the camera would be sent over a standard video calling system such asIMS (IP Multimedia Subsystem) to server 120. Server 120 would thendecode the barcode and process the verification of redemption. Barcodesused may be one-dimensional or two-dimensional, and may also use amulti-colored data storage system such as the Microsoft® Tag standard.

Scanner 145 is optionally included in a preferred embodiment. It may beintegrated with vendor terminal 140 or implemented as a separate unit.This scanner allows the user to present a token such as a printedbarcode or user terminal 105 in order to redeem an activated offer.Scanner 145 preferably reads a barcode representing the activated offercode from the user device. Scanner 145 may also optically read frompaper, such as a printed email or web page in which the offer code wasdistributed to the user as a barcode or number. Scanner 145 preferablyalso has near-field communication functionality, where software on userterminal 105 such as the offer-distribution application provides scanner145 with an offer code wirelessly. This near-field communicationfunctionality could be implemented using standards such as ECMA-340,ECMA-352, or FeliCa™.

FIG. 2 is a connection flow diagram suitable for use with the exemplaryembodiment of the invention shown in FIG. 1. FIG. 2 illustrates theconnection between user terminal 105 and server 120 during a typicalgameplay scenario.

The user initiates the gameplay process by launching a gameplayapplication on user terminal 105, or by navigating a web browser on userterminal 105 to a predetermined web address.

Step 205 is executed if the user does not have an account set up. Theuser enters personal account details such as name, password, phonenumber, preferred location, and demographic information into userterminal 105, and the user triggers the account creation.

Upon receiving this trigger, the user-entered account creation detailsare sent to server 120 in step 210. Server 120 creates the account,stores the account details in database 125, and sends an accountcreation confirmation to user terminal 105 in step 215.

Step 220 is executed when the user already has an account. The userenters a username and password into user terminal 105 and causes thelogin request to be sent to server 120 in step 225. If the credentialsprovided are valid, a login confirmation is returned to user terminal105 in step 230. Alternatively, a third-party social networking servicemay be used for authentication and identification, in which case amultiparty authentication process involving social networking server 135would be caused. In the preferred embodiment, user terminal 105 stores alogin cookie so that repeating the login process should not usually benecessary.

Step 235 is executed to get device location to send to the server. Insome cases this device location may be disabled by the user orunavailable, in which case a request with no location or a request witha location previously entered by the user may be sent. A request forpotential offers, preferably including the location, is sent to server120 in step 240. Server 120 processes this request, searches database125 for potential offers filtered by the given location, and returns thepotential offers in step 245 to user terminal 105. The response of step245 preferably includes information such as category, description, andan identifier of an associated game. Server 120 may also include offerswithout a location constraint in the response of step 245. If nolocation was provided in step 240, server 120 may either return onlyoffers without a location constraint, or alternatively use a previoususer location from database 125 or estimate the user's location bysending the user's IP address to a geolocation service. In step 240, theserver may also consider the user's playing history and use this data toreturn prioritization information with the list of offers. Thisprioritization information would reflect which offers are most likely tobe of interest to the user. Prioritization information could bedetermined by simple techniques such as monitoring which categories ofoffer the user most commonly plays for over time, or it could usemachine learning or other statistical techniques to correlate specificoffers to other offers in terms of shared interest by the same user.

In step 250, potential offers are displayed on user terminal 105,preferably in a flickable grid format. Potential offers may becolor-coded or sorted by category. If prioritization information wasreturned by the server, the highest-priority potential offers may besorted so that they are displayed first or may be shown in a separatearea.

In step 255, the user selects a potential offer to pursue. Preferably,the user can select one of these potential offers by tapping, whereupona detail window opens to display more detail (preferably includinginformation such as a potential offer end time) and the user can decidewhether to play the game. In a preferred embodiment, this window alsoprovides a link to a high score list (or “leaderboard”). If this isrequested it may be downloaded in steps 260 and 265. In some embodimentsthe leaderboard is automatically downloaded and displayed on userterminal 105 at the end of a game.

In step 270, a game, preferably time-limited, associated with theselected potential offer is presented to the user. In certainembodiments, user terminal 105 will download skinning images or gameplaycustomization settings for the game from server 120 specific to theparticular offer selected. This is expected to help promote the sponsorand the sponsor's products.

In step 275, a result of the game, preferably including at least onescore, is sent to server 120. In step 280, server 120 stores this resultin database 125. In step 183, server 120 generates an activated offerand offer code to send to the user terminal 105 in step 285. Thisactivated offer and offer code may be conditional on performance orrank. For example, a pizza company sponsor may provide a free pizza toanyone who scores over 200 points, or who ranks within the top 5players.

In step 292, generation of an activated offer is postponed until theconclusion of a potential offer time period or tournament. This wouldoccur in situations such as where the sponsor has chosen to give prizesto the top 5 players on Tuesday, and the final results will not be knownuntil the relevant time period has lapsed. In step 295, the delayedoffer generated and sent to the user in step 298. User terminal 105 thendisplays the activated offer in step 299.

In steps 285 and/or 295, the offer code may be sent to the user throughseveral means. It may be sent as a barcode, for example, or as a codefor use over NFC connection, or as text, or as a number. It may be sentto the user's email account, as an SMS to a mobile phone, through anotification architecture such as that provided by Apple iOS™, or anXML-based web service connection. In a preferred embodiment, all of thecommunication links in FIG. 2 take place over an XML-based web serviceconnection.

In one embodiment, multiple users can link their accounts, similar to asocial network, to merge their scores in a game or tournament. Thisallows multiple people to work together to win a game and has thebenefit of encouraging viral marketing of the sponsors' products. Inthis case, the users would indicate to user terminal 105 the account tolink to, and this would be sent by user terminal 105 to server 120 andstored in database 125. Server 120 would take these linkages intoconsideration when determining users' scores and winners ofcompetitions. These linkages may also require confirmation from the userbeing linked to prior to going into effect; this confirmation could berequested by way of an automatic e-mail, an SMS, or a mobilenotification architecture.

In a preferred embodiment, a settings screen is provided on userterminal 105 where location settings can be set. The user can enter adefault location, turn real time location reporting on or off, and set aradius in which to search for offers.

In a preferred embodiment, server 120 exposes an XML web service API, oralternatively a web application, for creating, reading, updating, anddeleting potential offers. Through this API, server 120 receives arequest from sponsor terminal 130 to create, read, update, or delete apromotional offer. Server 120 then stores in database 125 informationsuch as timing information, location information, a selection of one ormore games suitable for play by one requesting a promotional offer, gameconfiguration, images to skin a particular game with promotionalmessages, and offer information such as the discount or reward whichcomes with the offer. Server 120 also may provide analytics data to XMLweb service clients upon receiving a request therefor, potentiallyincluding information such as number of users playing, time of dayplaying, location of users, and other analytic information as istypically available in advertising platforms.

In a preferred embodiment, when an offer is displayed, the user isprovided an option to share it over a social network. Upon the user'sselection of this option, a message is sent to server 120 or socialnetwork server 135 to cause this sharing.

In a preferred embodiment, if a user is logged into the user's account,preferably through user terminal 105, and sends a request for pendingactivated offers to server 120, server 120 will respond with a list ofpending activated offers in the user's account.

FIG. 3 is a screenshot of a display on user terminal 105 of FIG. 1 instep 250 of FIG. 2. Area 305 is a tiled display of the potential offersfor the present location. Each of these offers preferably shows acategory, title, and offer. In addition, in some embodiments each ofthese offers could show a distance from the user terminal's currentlocation. Button 310 causes user terminal 105 to display a map view ofthe offers by location. Button 315 causes a category view to bedisplayed to allow the user to filter potential offers by category.Button 320 opens a view of offers the user has won or competed for.Button 325 opens the settings screen. Button 330 allows the user tochange account details.

FIG. 4 is a screenshot of a display on user terminal 105 of FIG. 1 instep 270 of FIG. 2. This figure depicts a slot machine-style game. Area405 displays an advertisement fetched from a server. Area 410 shows thetime remaining to play the game. Area 415 shows the top score as fetchedfrom server 120. Area 420 shows the reels; certain combinations of reelsincrease the user's score and others (three lemons, for example)decrease the user's score. The user's score is shown in area 425. Button430 causes the reels to spin and the score to be updated based on theending position of the reels. Button 435 ends the game and goes back tostep 250. If button 435 is not pressed before time expires, the processcontinues to step 275.

FIG. 5 is a screenshot of a display on user terminal 105 of FIG. 1 instep 270 of FIG. 2. This figure depicts a spinning wheel-style game.Area 505 displays an advertisement fetched from a server. Area 512 showsthe time remaining to play the game. Area 510 shows the top score asfetched from server 120. Area 520 shows the wheel; the ending positionof the wheel can increase or decrease the user's score based on themarkings on the wheel. The user's score is shown in area 515. Button 525causes the wheel to spin and the score to be updated based on the endingposition of the wheel. Button 530 ends the game and goes back to step250. If button 525 is not pressed before time expires, the processcontinues to step 275.

FIG. 6 is a screenshot of a display on user terminal 105 of FIG. 1 instep 270 of FIG. 2. This figure depicts a scratch-and-win-style game.Area 605 displays an advertisement fetched from a server. Area 612 showsthe time remaining to play the game. Area 610 shows the top score asfetched from server 120. Area 620 shows the scratch card; the numbersunder the scratched squares increase or decrease the user's score by themarked amount. The user's score is shown in area 615. To scratch acircle on the scratch card, the user can tap in area 620. Button 630ends the game and goes back to step 250. If button 630 is not pressedbefore time expires, the process continues to step 275.

FIG. 7 is a screenshot of a display on user terminal 105 of FIG. 1 afterplaying a game. In the embodiment depicted, area 715 displays ahigh-score list fetched from the server in step 360 and 265. Area 710displays the user's score from playing the game in step 270. Button 720triggers step 290, display of the activated offer. Area 705 displays anadvertisement fetched from a server. Button 725 exits the game screenand goes back to step 250 or step 270, as desired.

FIG. 8 is a connection flow diagram suitable for use with the exemplaryembodiment of the invention shown in FIG. 1. FIG. 8 illustrates theconnection between vendor terminal 140 and server 120 during a typicalredemption scenario. Connections take place preferably through an XMLweb service API or alternatively through non-web service HTTPconnections (such as in a web application) or potentially a remotecommunication system other than HTTP. In some embodiments, a telephone,SMS, or email interface may accept requests for validation andredemption of activated offers rather than vendor terminal 140.

In step 805, the vendor terminal receives an offer code. For example,this can be input manually by the vendor, or automatically from scanner145.

In step 810, the vendor terminal receives input specifying that theactivated offer should be validated. In some embodiments, validationcould be performed automatically in response to receiving an offer code,and in other embodiments the validation may not be performed at all.

In response to the request for validation, in step 815 a request forvalidation of the activated offer, containing an offer code, is sent toserver 120. In step 820, server 120 queries database 125 to see if theoffer is valid and what it can be redeemed for. This result is sent backto the vendor terminal in step 825 and is indicated to the vendor instep 830. Step 830 may comprise visual or audio indication of thevalidity of the offer.

In step 840, the vendor terminal receives input specifying that theactivated offer should be redeemed. In some embodiments, redemptioncould be performed automatically in response to receiving an offer code.In response to the redemption input, a request for redemption of theactivated offer is sent to server 120 in step 845.

In response to the request for redemption, in step 850 server 120queries database 125 to see if there is enough residual value to fulfillthe amount of the request for redemption. If there is enough value,server 120 deducts the amount of the request from the value remaining inthe activated offer and stores the new value in database 125. Thisstoring causes at least part of the value of the activated offer to nolonger be usable.

In step 855 server 120 causes billing of the sponsor. In a preferredembodiment some vendors may elect to pay for the distribution of offersbased on the number or value of offers redeemed. In this case, it isimportant to mark information about redemptions in database 125 so thatthe sponsor can be correctly billed. This could be accomplished inseveral ways: the sponsor's account could be updated in database 125after each redemption, or the redemption of the activated offers couldsimply be indicated in database 125 after each redemption, with billingcalculated at a later stage. In any case, this update of database 125would cause the sponsor's account to be charged a certain incrementalamount, potentially depending on the type of redemption. In analternative embodiment a vendor may choose to pay based on offersawarded rather than offers redeemed; in such an embodiment server 120would calculate billing responsive to the activation of offers.

In some embodiments the billing to the sponsor responsive to theredemption comprises either the majority or the entirety of the chargesbilled to the sponsor for the distribution of offers.

In step 860, server 120 causes an alert to be sent to the user. Thiscould be sent using e-mail, SMS, or a notification mechanism such asthat implemented in mobile operating systems such as Apple® iOS. Someembodiments do not include this alert. This alert could be enabled ordisabled by a user preference. The alert reduces fraud by alerting thecustomer if a redemption happens to be made fraudulently by anotherparty who has obtained the user's offer code.

In step 865, server 120 sends a response to vendor terminal 140 toindicate whether or not the redemption was successfully completed. Instep 870, vendor terminal 140 indicates to the vendor through a visualor auditory indication whether or not the redemption was successful. Ifthe redemption is successful, the vendor can then provide the product orservice offered in the activated offer to the user.

1. A method for differentially distributing promotional offers,comprising: a. receiving a request for currently available potentialoffers for a user; b. transmitting a list of potential offers fromvendors based on location data for the user's account or device, whereinat least one of the potential offers from at least one of the vendorshas a game associated with it, the play of which allows for a score tobe determined that affects the offer to be made; c. determining orreceiving a resulting score for the user's play of such game; and d.giving a currently available potential offer to the user wherein theoffer given is dependent at least in part on the rank of the user'sscore in comparison to other users' scores in the play of such game. 2.The method of claim 1, in which said transmitting includes at least twopotential offers, each from different vendors, and each having a gameassociated with it, the play of which allows for a score to bedetermined that affects the offer to be made.
 3. The method of claim 1,which additionally includes the step of giving a delayed offer after adelay.
 4. The method of claim 1, in which said transmitting stepcomprises including category information for at least one of thepotential offers.
 5. The method of claim 1, in which said transmittingstep comprises including information based on the user's playinghistory.
 6. A method for accepting promotional offers for distributioncomprising: a. receiving a request from a sponsor to create apromotional offer; b. storing in a database (1) timing information, (2)location information, (3) a selection of one or more games suitable forplay by one requesting a promotional offer, and (4) offer information,all related to the promotional offer; and c. distributing a promotionaloffer using data from each category stored in said storing step.
 7. Themethod of claim 5, wherein said storing of the offer informationcomprises, storing the offer information to include one offer to begiven to game players who do not meet a performance bar, and a separate,second offer to be given only to game players who meet a performancebar.
 8. The method of claim 5, wherein said storing of the offerinformation comprises, storing the offer information to include oneoffer to be given to game players who do not meet a performance bar, anda separate, second offer to be given only to game players dependent ontheir rank relative to other game players.
 9. A method for providing apromotional offer to a user, comprising: a. receiving a list ofcurrently available potential offers from a server; b. presenting alocation-filtered list of currently available potential offers to auser; c. receiving a selection of a currently available potential offerfrom the user; d. presenting a game to the user based on the selection;e. transmitting a score of the user in the game to a server; f.receiving an activated offer from the server, wherein the choice of theactivated offer is based at least in part on the score; and g.presenting the activated offer to the user.
 10. The method of claim 9,wherein said presenting a location-filtered list takes place through atouchscreen display on a mobile device.
 11. The method of claim 10,wherein said mobile device is a cellular phone.
 12. The method of claim9, wherein said presenting a location-filtered list takes place on a mapdisplay.
 13. The method of claim 9, wherein the choice of the activatedoffer is determined by whether or not the user had the highest score.14. The method of claim 9, wherein said presenting a game step comprisespresenting a slot-machine-style game.
 15. The method of claim 9, whereinsaid presenting a game step comprises presenting a spinning-wheel-stylegame.
 16. The method of claim 9, wherein said presenting a game stepcomprises presenting a scratch-and-win-style game.
 17. The method ofclaim 9, wherein said receiving an activated offer step comprisesreceiving a delayed offer after the game has been concluded.
 18. Themethod of claim 9, wherein the location-filtered list is filtered orsorted based on the user's playing history.
 19. A method for acceptingpromotional offers for distribution comprising: a. receiving a requestfrom a sponsor to create a promotional offer; b. storing in a databaseinformation related to the promotional offer; c. distributing anactivated promotional offer to a user based on a result of gameplay; d.receiving a request for redemption of the activated promotional offerfrom a vendor terminal; e. processing redemption of the activatedpromotional offer; and f. responsive to the redemption, billing a chargeto the sponsor.
 20. The method of claim 19, wherein said billing acharge to the sponsor responsive to the redemption comprises themajority of the charges billed to the sponsor for the distribution ofoffers.
 21. The method of claim 19, wherein said billing a charge to thesponsor responsive to the redemption comprises the entirety of thecharges billed to the sponsor for the distribution of offers.
 22. Themethod of claim 19, wherein in said receiving the request for redemptioncomprises receiving a request for less than the full value of theactivated promotional offer, and a portion of the balance is retainedfor subsequent redemption.